System for on-line and off-line decryption

ABSTRACT

A secure communication system wherein message decryption may be performed while off-line, or optionally while on-line. A sender encrypts a message based on the message key and sends it to the recipient. An envelope containing a message key is created by encrypting the message key based on a verifier, where the verifier is based on a secret of the recipient. The recipient is provided the envelope, along with the message or separately, from the sender or from another party, contemporaneous with receipt of the message or otherwise. The recipient can then open the envelope while off-line, based on their secret, and retrieve the message key from the envelope to decrypt the message. In the event the recipient cannot open the envelope, optional on-line access permits obtaining assistance that may include obtaining an alternate envelope that the recipient can open.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/449,068, filed Feb. 20, 2003.

BACKGROUND OF INVENTION

[0002] 1. Technical Field

[0003] The present invention relates generally to secure electroniccommunication and more particularly to encryption and decryption ofe-mail and other messages, files or other information.

[0004] 2. Background Art

[0005] A key server may be used for managing and distributing symmetricencryption keys, that is, keys for an encryption system in which theencryption key and the decryption key for a particular message are thesame. For example, in a secure e-mail system, a sender of an e-mail mayrequest that the key server create and store a message key, that is, anencryption/decryption key for a message that is unique to thatparticular message or unique for a particular series of messages. Thesender then encrypts the e-mail with the message key and sends it to therecipients. A given recipient then requests the message key from the keyserver, which determines the authenticity of the recipient. If therecipient is authentic and is also authorized to receive the message key(as specified by the original sender), the key server delivers themessage key to the recipient, which uses the message key to decrypt thee-mail.

[0006] Distributing symmetric keys via a key server has many positiveattributes. For example, a sender (or any authorized party) candetermine when a recipient has requested and received the message key.This “key advisement” can form the basis of an audit system. Also, asender (or any authorized party) can control access to the message key,including specifying not-before and not-after delivery times for a key.In this way, the message key can be made available only during a certaintime window, or access can be terminated if conditions warrant denyingany further access to the message.

[0007] Most present key server schemes make off-line decryptionimpossible because they require that the recipients be on line tocommunicate with the key server. There are some exceptions to this,however, and these off-line decryption systems generally use keyenveloping via one of the following schemes. First, a sender can encrypta message with a message key that is chosen at random. The message keyis then encrypted (i.e., enveloped) with another key that is derivedfrom a password known to the sender and all of the recipients. Second,as above, except that the message key is encrypted with a public key ofthe recipient. In either case, there is typically one envelope perrecipient, particularly in the second scheme where each recipient'spublic key is different.

[0008] The first scheme above is weak. Enveloping a message key withanother key that is derived from a password is susceptible to off-linedictionary attacks on the password. Given that most passwords need to bememorized by human users, and given that passwords must consist ofprintable characters, the effective length of a key derived from apassword is anywhere from 1.5 to 5 bits per character. Thus, theeffective length of a key derived from a twelve character password(which has 50% more characters than a typical password of eightcharacters) is anywhere from 18 to 60 bits. By today's standards, such akey is very weak and is subject to brute force attacks. In summary, akey derived from a password is subject to both off-line dictionaryattacks as well as brute force attacks.

[0009] The second scheme above is very strong. However, enveloping amessage key with the recipient's public key imposes burdensomerequirements. For example, all intended recipients must already have apublic key, and those must be available to the sender at the time ofenveloping. In cases where the sender and recipients are new to eachother, simply ascertaining public keys can be an obstacle. Setting up,by obtaining public and private keys and such, can also be daunting whena recipient is new to the scheme. Not surprisingly, many potentialrecipients opt out if any other options exist, even less secure ones,and many resist adoption until they expect to receive substantialnumbers of messages secured in this manner. Furthermore, the private keyof each recipient must be available at the place where that recipientdesires to read the message. For instance, if a recipient stores hisprivate key at a computer at work, he would not be able to decrypt themessage at a home computer that does not also have a copy of therecipient's private key.

[0010] In summary, a password-based scheme is easy to use but offersweak security. A public key scheme offers strong security but is verydifficult to deploy and use. Because of the reasons mentioned above, thecurrent state-of-the-art off-line decryption systems do notsimultaneously satisfy both security and ease-of-use requirements.

SUMMARY OF INVENTION

[0011] Accordingly, it is an object of the present invention to providea secure communication system that can simultaneously satisfyrequirements of high security and high ease of use.

[0012] Briefly, one preferred embodiment of the present invention is asystem for secure communication of a message from a sender to arecipient. An envelope is created containing a message key, byencrypting the message key based on a verifier that is based on a secretof the recipient. The message key is provided to the sender, where themessage is encrypted based on the message key. The message is sent fromthe sender to the recipient. The envelope is also provided to therecipient, typically but not necessarily along with the message. Therecipient then open the envelope. This is done based on the secret ofthe recipient, and the recipient is then able to retrieve the messagekey from the envelope and decrypt the message based on the message key.

[0013] Briefly, another preferred embodiment of the present invention isa system for a sender to encrypt a message intended for a recipient. Amessage key is provided. Then an envelope is created containing themessage key, by encrypting the message key based on a verifier that isbased on a secret of the recipient. The message is encrypted, based onthe message key. This then permits the message to be sent securely fromthe sender to the recipient and, when the recipient is provided with theenvelope, typically but not necessarily along with the message, thesecret can be used to open the envelope to retrieve the message key anddecrypt the message.

[0014] Briefly, yet another preferred embodiment of the presentinvention is a system for a recipient to decrypt a message secured witha message key. An envelope is received that is based on a secret of therecipient, wherein the secret corresponds with a verifier used to createthe envelope. The envelope is then opened to retrieve the message key.Finally, the message is decrypted based on the message key.

[0015] An advantage of the present invention is that it provides bothhigh security and high ease of use. With respect to improved security,the present invention uses encryption of message keys (enveloping) basedon a verifier, rather than relying upon an envelope key derived directlyfrom a password and the inherent weakness such introduces. With respectto improved ease of use, the present invention uses such enveloping anddecryption (de-enveloping or envelope opening) to access the message keybased on a corresponding secret, rather than a more complex scheme likepublic key infrastructure (PKI).

[0016] And another advantage of the invention is that embodiments of theinvention optionally employ a mixture of on-line and off-line decryptioncapabilities, further combining high security high flexible utility.

[0017] These and other objects and advantages of the present inventionwill become clear to those skilled in the art in view of the descriptionof the best presently known mode of carrying out the invention and theindustrial applicability of the preferred embodiment as described hereinand as illustrated in the several figures of the drawings.

BRIEF DESCRIPTION OF DRAWINGS

[0018] The purposes and advantages of the present invention will beapparent from the following detailed description in conjunction with theappended figures of drawings in which:

[0019]FIG. 1 (background art) is a functional block diagram of anon-line secure communication system.

[0020] FIGS. 2A-C (background art)(extending across three sheets) is anetwork data flow diagram of an example message encryption, sending, anddecryption that occurs within the secure communication system of FIG. 1.

[0021]FIG. 3 is a functional block diagram of an online/off-line securecommunication system according to the present invention.

[0022] FIGS. 4A-B (extending across two sheets) is a network data flowdiagram of an example message encryption, sending and decryption processthat occurs within the improved secure communication system of FIG. 3.

[0023] In the various figures of the drawings, like references are usedto denote like or similar elements or steps.

DETAILED DESCRIPTION

[0024] A preferred embodiment of the present invention is a system foron-and off-line decryption in the greater context of a securecommunication system. As illustrated in the various drawings herein, andparticularly in the view of FIG. 3, a preferred embodiment of theinvention is depicted by the general reference characters 130.

TERMINOLOGY

[0025] Unless stated otherwise, the following terminology is usedherein.

[0026] Message key, encryption key, decryption key, or simply the keymean the symmetric key that is used to encrypt or decrypt a message.

[0027] Message means the unit of data that is encrypted and decrypted.Throughout this document we use e-mail as an example of a message.However, other kinds of messages are also envisioned. These includeinstant messages, chat messages, messages communicated between twoapplications using a protocol other than e-mail (SMTP) and manners oftransferring files other than as e-mail attachments (e.g., FTP), etc.

[0028] Sender means the encryptor of the message.

[0029] Recipient, sometimes called receiver, means the decryptor of themessage. The list of recipients can include the sender, or even besolely the sender. This is the case when a person encrypts a message forsecure communication or storage so that only he or she can decrypt itlater.

[0030] Envelop key means the symmetric key that encrypts/decrypts themessage key, wherein an envelop encryption key is the public key thatencrypts the message key and an envelop decryption key is the private orsecret key that decrypts the message key.

[0031] Key exchange algorithm means the algorithm a sender and therecipients use to derive the envelop key.

[0032] Key encryption algorithm means the algorithm the sender andrecipients use to encrypt or decrypt the envelop key.

[0033] Session key means an encryption/decryption key that is used tosecure on-line communication between various components of the system.Session keys are preferably temporary and not stored on any server.

A Background Art on Line Encryption/Decryption System

[0034]FIG. 1 (background art) is a functional block diagram of a securecommunication system 100 that the present invention improves upon. Thesecure communication system 100 here consists of three major components:clients 102, an authentication server 104, and a key server 106. Theclients 102are conceptually viewed as one component because senders 108and recipients 110 collectively are both “clients” of the authenticationserver 104 and key server 106. All interactions between the clients 102(that is, either a sender 108 or a recipient 110) and the authenticationserver 104 or the key server 106 may be encrypted using short-livedsession keys.

[0035] FIGS. 2A-C (background art)(with parts A through C extendingacross three sheets) is a network data flow diagram of an examplemessage encryption, sending, and decryption that occurs within thesecure communication system 100. Each of FIG. 1 and FIGS. 2A-C show theprocess activities associated with the major components of the securecommunication system 100 for encryption and decryption of an examplemessage 112. These process activities are as follows.

[0036] A1: The sender 108 authenticates by sending an authenticationrequest 114 to an authentication server 104.

[0037] A2: The authentication server 104 authenticates the sender 108via whatever method is appropriate. Various methods can be supported,and multiple ones can be supported concurrently. Which particular methodis used, however, is not particularly germane here. Upon successfulauthentication, the authentication server 104: creates a digitallysigned sender assertion 116, vouching for the identity of the sender108.

[0038] A3: Subject to successful authentication, the authenticationserver 104 sends the sender assertion 116 to the sender 108.

[0039] A4: The sender 108 sends a sender key request 118 to the keyserver 106. The sender key request 118 includes the sender assertion 116and a recipient list 120 of authorized recipients 110 of the message112, and formally requests a message key 122.

[0040] A5: The key server 106 validates the sender assertion 116,creates the message key 122, and stores the message key 122 along withthe recipient list 120 in an internal database.

[0041] A6: The key server 106 sends the message key 122 to the sender108.

[0042] A7: The sender 108 encrypts the message 112 using the message key122.

[0043] A8: The sender 108 sends the encrypted message 112 to therecipients 110. There may be many intermediary relays (not shown in thefigures) between the sender 108 and each recipient 110. Theseintermediaries simply relay the message 112 but are not privy to themessage key 122, unless a particular intermediary also happens to be arecipient 110of the message 112.

[0044] A9: The recipient 110 sends an authentication request 124 to anauthentication server 104. The authentication server 104 with which arecipient 110 authenticates may be, but need not be, the same as theauthentication server 104 with which the sender 108 authenticates. Theauthentication request 124 here can be substantially the same as anauthentication request 114 that a sender 108 authenticates with, butthat is not a requirement and different criteria may apply.

[0045] A10: The authentication server 104 authenticates the recipient110 via whatever method is appropriate. Again, various methods can besupported. Upon successful authentication, the authentication server 104creates a digitally signed recipient assertion 126, vouching for theidentity of the recipient 110. The recipient assertion 126 here can alsobe substantially the same as a sender assertion 116 vouching for theidentity of the sender 108, but that is also not a requirement.

[0046] A11: Subject to successful authentication, the authenticationserver 104 sends the recipient assertion 126 to the recipient 110.

[0047] A12: The recipient 110 sends a recipient key request 128 to thekey server 106. The recipient key request 128 includes a resource ID(which uniquely identifies the decryption key) and the recipientassertion 126, and formally requests the message key 122.

[0048] A13: The key server 106 validates the recipient assertion 126,checks its internal database to confirm that the recipient 110 is in therecipient list 120, and retrieves the message key 122.

[0049] A14: The key server 106sends the message key 122 to the recipient110.

[0050] A15: The recipient 110 uses the message key 122 to decrypt themessage 112.

[0051] There must exist an a-priori trust relationship between theauthentication server 104 (or authentication servers 104, if more thanone is employed) and the key server 106. That is, the key server 106must trust the authentication server 104 to vouch for the identity of aset of clients 102. Said another way, the key server 106 must verifythat the assertions the clients 102 provide to the key server 106 havebeen created by the authentication server 104 and have not beenmodified. The key server 106 can implement this trust relationship byacquiring a public verification key of the authentication server 104(e.g., a X.509 certificate of the authentication server 104, bearing itspublic key). The authentication server 104can then use its correspondingprivate key to sign the assertions 116, 126.

[0052] The secure communication system 100 shown in FIG. 1 requires thatthe sender 108 and all of the recipients 110 be on-line to receive themessage key 122, though it is not required that the sender 108 and anyrecipient 110 be on-line at the same time.

Adding Off-Line Decryption

[0053] We now describe how the secure communication system 100 justdescribed can be extended to also provide an off-line decryptioncapability whereby, subsequent to receipt of an encrypted message, arecipient need not communicate with any other component in order todecrypt the message. Suitable embodiments of the invention can alsoprovide on-line decryption capability when off-line decryption is notpossible (e.g., when a recipient has forgotten his or her password). Andsuitable embodiments can enable a sending organization to implement apolicy that satisfies on-line and off-line decryption requirements on aper-recipient basis.

[0054] Off-line decryption relies on an encryptor having access to eachrecipient's verifier. A verifier is analogous to a public key. However,instead of a having a random public/private key pair, a verifier iscreated based on a known secret (typically, a password). Verifiers areknown in the art; see for example, the Secure Remote Password (SRP)proposed by THOMAS WU in IETF RFC 2945, “The SRP Authentication And KeyExchange System”. A party who knows a verifier can challenge a party whoclaims to know the corresponding secret. However, the secret need not bedivulged to the challenging party. Nor is it feasible for any party thatknows the verifier to guess the corresponding secret.

[0055]FIG. 3 is a functional block diagram of a secure communicationsystem 130 according to the present invention. The secure communicationsystem 130 consists of three major components: clients 102, anauthentication server 104, and a key server 106. The clients 102 areagain conceptually viewed as one component because the senders 108 andrecipients 110 collectively are both “clients” of the authenticationserver 104 and the key server 106. The authentication server 104 may bethe same as in the secure communication system 100 of FIG. 1 and FIGS.2A-C (background art). The key server 106 now has additionalcapabilities, however. And, as discussed presently, a key server 106 mayalso be used in embodiments of the invention that operate in the mannerof the secure communication system 100 and alternately in the manner ofthe secure communication system 130. Also, as was the case for thesecure communication system 100, all interactions between a client 102(that is, either a sender 108 or a recipient 110 and either theauthentication server 104 or the key server 106 may be encrypted usingshort-lived session keys.

[0056] FIGS. 4A-B (in parts A and B extending across two sheets) is anetwork data flow diagram of an example message encryption, sending anddecryption process that occurs within the secure communication system130. Each of FIG. 3 and FIGS. 4A-B show the process activitiesassociated with the major components of the secure communication system130 for encryption and decryption of an example message 112. Theseprocess activities are as follows.

[0057] B1: The sender 108 authenticates by sending an authenticationrequest 114 to an authentication server 104

[0058] B2: The authentication server 104 authenticates the sender 108via whatever method is appropriate (various and multiple methods can besupported for this). Upon successful authentication, the authenticationserver 104 creates a digitally signed sender assertion 116, vouching forthe identity of the sender 108.

[0059] B3: Subject to successful authentication, the authenticationserver 104 sends the sender assertion 116to the sender 108.

[0060] B4: The sender 108 sends a sender key request 118 to the keyserver 106. The sender key request 118 includes the sender assertion116and a recipient list 120 of authorized recipients 110 of the message112, and formally requests a message key 122.

[0061] Activities B1 through B4 may be essentially the same asactivities A1 through A4, described with respect to FIG. 1 and FIGS.2A-C.

[0062] B5: The key server 106 validates the sender assertion 116,creates the message key 122, and places the message key 122 in anenvelope 132. Each message 112 may have one or more message keys 122.For instance, multiple message keys 122 might be used when a message 112has multiple parts like a body and one or more attachments. Each messagekey 122 may also be put in multiple envelopes 132, usually one perrecipient 110. A single envelope 132 might also be used for multiplerecipients 110, but that is generally not desirable because eachrecipient 110 would then have to know the corresponding secret(s) thatopens the envelope 132. Additionally, in a typically used option that isdiscussed further presently, the key server 106 can also store themessage key 122 along with the recipient list 120 in an internaldatabase.

[0063] B6: The key server 106 sends the message key 122 and all of theenvelopes 132 (each containing an encrypted copy of the message key 122)to the sender 108.

[0064] B7: The sender 108 encrypts the message 112 with the message key122.

[0065] B8: The sender 108 sends the encrypted message 112 along with theenvelopes 132 to the recipients 110. All of the recipients 110 can besent all the envelopes 132 (which are generally small), or traffic canbe reduced by providing each recipient 110 with only the envelope 132 itwill need. There may be many intermediary relays between the sender 108and the recipient 110 (not shown in the figures). The intermediariessimply relay the message 112 but are not privy to the message key 122 orthe contents of any envelope 132, unless an intermediary also happens tobe an authorized recipient 110 of the message 112.

[0066] Activities B5 through B8 are modified from activities A5 throughA8, described with respect to FIG. 1 and FIGS. 2A-C.

[0067] B9: The recipient 110 uses the secret 136, corresponding with theverifier 134, to open (decrypt) the appropriate envelope 132 to obtainthe message key 122.

[0068] B10: The recipient 110 uses the message key 122 to decrypt themessage 112.

[0069] Activity B9 replaces activities A9 through A14 and activity B10may be essentially the same as activity A15, as described with respectto FIG. 1 and FIGS. 2A-C.

Creating the Verifier

[0070] The secure communication system 130 just described uses theverifier 134 to create the encrypted envelopes 132, which contain themessage key 122. There are multiple methods by which the key server 106can know the verifier 134 for each recipient 110, five of which aredescribed below. Also, each envelope 132 could use a different method;that is, enveloping for all recipients 110 need not use the same method.

[0071] First, the key server 106 may ask the authentication server 104for a verifier 134 for each recipient 110. In this case, one or more ofthe following may apply. The authentication server 104 may already havethe verifier 134; the authentication server 104 may have the secret136of the recipient 110, and thus be able to create the verifier 134 onthe fly; or the authentication server 104 may have data that isequivalent to the secret 136 (e.g., a hash of the secret 136), and cancreate the verifier 134 on the fly from this.

[0072] Second, the key server 106 may create the verifier 134 on the flyby asking the authentication server 104 for the secret 136 of therecipient 110, or for data that is equivalent to it (e.g., a hash ofit). Third, the sender 108 can provide the verifier 134 of a recipient110 to the key server 106, based on a-priori knowledge of the verifier134. Fourth, the sender 108 can create the verifier 134 of a recipient110 on the fly and provides it to the key server 106. And fifth, the keyserver 106 can create the verifier 134 on the fly, based on the secret136 which the sender 108 provides.

[0073] The sophisticated variations of the secure communication system130 described above use the key server 106, but even this is not arequirement. The sender 108 can have or create the verifier 134, andthen use it itself to create the envelope 132. The sender 108 can dothis using a message key 122 obtained from a key server 106, with orwithout involvement of an authentication server 104, or the sender 108can have or create the message key 122.

The Enveloping Algorithm

[0074] There are various possible methods for creating the envelope 132containing the message key 122, two of which are now discussed. First,the verifier 134 can be used to create an envelope key. One suitabletechnique for this is to derive the envelop key via the publicly-knownDiffie-Hellman key agreement. For example, the creator of the envelopekey may use the verifier 134 to arrive at, say, some 2,000 bits of data,wherein the recipient 110 will be able to arrive at those same 2,000bits of data by using the secret 136. Then, a conventional encryptionalgorithm (e.g., AES) can be used to encrypt the message key 122 withthe envelop key, thereby creating the envelope 132. This requires thecreator of the envelope 132 to include how the envelop key was derivedand what algorithm was used to encrypt the message key 122. Continuingwith our example, since only, say, 128 bits are needed by the encryptionalgorithm, some accord or advisement is needed whereby the recipient 110will know which 128 bits out of the available 2,000 bits the envelopekey creator used and, furthermore, which encryption algorithm was used.

[0075] Second, the verifier 134 can be more directly used to create theenvelope 132 itself. That is, an encryption key for the envelope 132 canbe based on the verifier 134 and a corresponding decryption key for theenvelope 132 can be based on the secret 136 corresponding to theverifier 134 This method has the advantage that the creator of theenvelope 132 need not specify how the encryption key for the envelope132 was derived. One example technique suitable for this is to encryptthe message key 122 via the publicly-known El-Gamal encryptionalgorithm.

Some Alternative Embodiments

[0076] We now consider various alternative embodiments of the invention,some of which include a combination of aspects of the securecommunication systems 100, 130 described above, and others of whichbuild upon respective aspects of the secure communication systems 100,130.

[0077] On-line key retrieval, e.g., in the manner of the securecommunication system 100, and off-line decryption, e.g., in the mannerof the secure communication system 130, are not mutually exclusive.On-line key retrieval can be used as a fallback mechanism. As noted whendiscussing activity B5, above, the key server 106 can store the messagekey 122 in its database. In the case that a recipient 110 cannot openthe envelope 132, say, because the recipient 110 has forgotten thesecret 136 corresponding to the verifier 134 that was used to create theenvelope 132, the recipient 110 can be given the option to communicatewith the key server 106 and request the message key 122.

[0078] The sender 108 can communicate a key retrieval policy to the keyserver 106 to indicate exactly how each recipient 110 can retrieve themessage key 122. For example, a sender 108 can specify a set ofrecipients 110 that must get the message key 122 by retrieving it fromthe key server 106 (i.e., be on-line and request the message key 122from the key server 106), and the sender 108 can also specify a set ofrecipients 110 that can be off-line. The key server 106 creates andstores the message key 122. Additionally, the key server 106 can createthe envelopes 132 for only the set of recipients 110 who are authorizedto decrypt the message 112 off-line. Similarly, any authorized party(e.g., the key server 106 itself, an administration client of the keyserver 106, etc.) can set the key retrieval policy.

[0079] In cases where the key server 106 does not have access to theverifiers 134 of recipients 110, the sender 108 can create the envelopes132 and include them in the message 112. Note that in such a case, thekey server 106 operates in the manner of the secure communication system100, i.e., in an on-line mode. It is then the sender 108 that, uponreceiving the message key 122, creates the envelopes 132 and includesthem when sending the message 112.

[0080] There may also be a desire to eliminate the key server 106 alltogether, or to simply not use it. This is particularly advantageous inthe case of peer-to-peer communication, consisting of small sets ofsenders 108 and recipients 110. In such embodiments of the invention,the sender 108 creates the message key 122 and the envelopes 132. Thereis no on-line key retrieval capability if no key server 106 exists, orwhen a key server 106 does exist but has not been employed and does nothave the message key 122.

[0081] In a typical embodiment, the invention may employ theauthentication server 104 as the custodian of the verifiers 134, sinceit can easily create and store the verifiers 134 for its existing users(i.e., potential recipients 110. To make this easy and transparent, itcan be done whenever the authentication server 104 solicits a user'sprivate credentials for any reason, including ones that have nothing todo with creating assertions 116, 126 for accessing the key server 106.Typically a password is the credential or “secret” that is used.Furthermore, once the authentication server 104 has created and stored averifier 134, it can update it whenever a user changes their privatecredentials. This has two benefits. First, it makes creation of theverifier 134 transparent (though, users could be given notice of such anaction if their agreement is required). Second, the verifier 134 can beupdated transparently when a user changes their secret 136.

[0082] A verifier 134 is typically constructed from a secret 136 that isa password. However, this need not be the case. A verifier 134 can alsobe constructed from any number of attributes of the recipient 110,either public or private. For example, a verifier 134 could beconstructed based on a Social Security number, mother's maiden name,state of residence, etc. The strength of the verifier 134 isproportional to the number and secretive strengths of the attributesthat go into its construction.

[0083] As mentioned previously, in some embodiments of the invention,the authentication server 104 may be the custodian of the verifiers 134However, because verifiers 134 are generally public data, they need notbe stored in a trusted repository. Thus, yet other embodiments of theinvention can use a verifier repository that is separate from theauthentication server 104

[0084] An important limitation of an off-line decryption system is thatoff-line decryption is not possible if a recipient 110 forgets his orher secret 136. Moreover, if the recipient 110 changes the secret 136,all messages 112 enveloped using the old secret 136cannot be openedusing the new secret 136. As a result, the recipient 110 must remembermultiple secrets 136 (e.g., multiple passwords).

[0085] Some embodiments of the invention overcome these limitationsusing the following method. When a recipient 110 has changed the secret136 he must go on-line to retrieve the message key 122. Once on-line,the key server 106 can create a new envelope 132 (based on the currentverifier 134 for the current secret 136 of the recipient 110 and sendthat envelope 132 to the recipient 110. This allows for a reasonablyseamless roll-over of secrets 136 of the recipient 110. However, alimitation of this is that the recipient 110 must be on-line once forevery message 112 having a verifier 134 that no longer matches thecurrent secret 136. The key server 106 could send multiple envelopes 132using the new verifier 134. For example, if a user has 100 messages 112where the message keys 122 were enveloped using an old verifier 134,once on-line, the recipient 110 can get the new envelopes 132 from thekey server 106 for all 100 of the previous message keys 122 (or, evenone envelope 132 containing the 100 message keys 122).

[0086] While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of the invention should not belimited by any of the above described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents.

Industrial Applicability

[0087] The present secure communication system 130 is well suited forapplication in electronic communications of e-mail, other message types,files, and other information, concurrently providing both high securityand high ease of use for both on-line and off-line decryption.

[0088] Unlike the majority of prior art schemes, the present inventionpermits off-line decryption by message recipients. Alternately, thepresent invention can also permit on-line decryption, establishing thisas a requirement for some of multiple recipients or providing it as afall back, for instance, when a recipient forgets their password.

[0089] Further, unlike prior art off-line decryption schemes that useenveloping where a message key is encrypted based on an envelope keyderived directly from a password, and the notorious attendantsusceptibility of such to various types of attacks on the password, thepresent invention uses encryption based on a verifier that correspondswith a secret of the message recipient. Such verifiers may be madeconsiderably more substantial than passwords, yet the correspondingsecrets can be passwords, and thus can be easily remembered and used bythe recipients.

[0090] Furthermore, unlike other prior art off-line decryption schemesthat use complex arrangements like public key infrastructure (PKI)wherein large public keys must be ascertained, procured, stored, andavailable whenever and wherever one wishes to send or read a securedmessage, the present invention again uses the verifier/secret basedapproach where both the verifier and the secret are easily used by therespective parties employing them. While a verifier is analogous to apublic key, it is far less odious to use. Similarly, a secret is(remotely) analogous to a private key, and far less odious to use. Sincea secret can be a password, or based on some other public or privateattribute of the recipient, it is quite easy for recipients to rememberand work with secrets.

[0091] Nonetheless, while providing the noted and other advantages, thepresent invention may now be implemented by those of reasonable skill inthe art, creating embodiments using existing technologies if desired,and then used by individuals and organizations with ordinary skills andaptitudes.

[0092] For the above, and other, reasons, it is expected that the securecommunication system 130 of the present invention will have widespreadindustrial applicability. Therefore, it is expected that the commercialutility of the present invention will be extensive and long lasting.

1. A method for secure communication of a message from a sender to arecipient, the method comprising the steps of: creating an envelopecontaining a message key by encrypting said message key based on averifier that is based on a secret of the recipient; providing saidmessage key to the sender; at the sender, encrypting the message basedon said message key; sending the message from the sender to therecipient; providing said envelope to the recipient; and at therecipient: opening the envelope based on said secret of the recipient;retrieving said message key from the envelope; and decrypting themessage based on said message key.
 2. A method for a sender to encrypt amessage intended for a recipient, the method comprising the steps of:(a) providing a message key; (b) creating an envelope containing saidmessage key by encrypting said message key based on a verifier that isbased on a secret of the recipient; and (c) encrypting the message basedon said message key, thereby permitting the message to be sent securelywith said envelope from the sender to the recipient, and the recipientto be provided said envelope so that said secret can be used to opensaid envelope to retrieve said message key and decrypt the message. 3.The method of claim 2, wherein said step (a) includes generating saidmessage key at the sender itself.
 4. The method of claim 2, wherein saidstep (a) includes: obtaining said message key at a key server; and thesender receiving said message key from said key server.
 5. The method ofclaim 4, wherein said key server stores a copy of said message key. 6.The method of claim 5, wherein said step (a) includes instructing saidkey server whether and under what conditions said message key may bereleased to parties other than the sender itself.
 7. The method of claim5, wherein said step (a) includes: the sender providing a recipient listto said key server; and said key server storing a copy of said recipientlist.
 8. The method of claim 4, wherein said step (a) includesauthenticating the sender as a condition of said key server providingsaid message key.
 9. The method of claim 8, wherein said step (a)includes the sender submitting a sender assertion to the key server,wherein said sender assertion originates from an authentication server.10. The method of claim 2, wherein said step (b) includes: deriving saidenvelope key based on a key agreement protocol; and encrypting saidmessage key using a symmetric encryption algorithm.
 11. The method ofclaim 10, wherein: said key agreement protocol is the Diffie-Hellman keyagreement; and said encryption algorithm is the AES encryptionalgorithm.
 12. The method of claim 2, wherein said step (b) includesencrypting said envelope key directly with said verifier, therebypermitting decrypting said envelope directly with said secret.
 13. Themethod of claim 12, wherein said step (b) includes encrypting saidmessage key based on a public key encryption algorithm.
 14. The methodof claim 13, wherein said public key encryption algorithm is theEl-Gamal encryption algorithm.
 15. The method of claim 2, wherein saidstep (b) includes generating said envelope at the sender itself.
 16. Themethod of claim 2, wherein said step (b) includes: generating saidenvelope at a key server; and the sender receiving said envelope fromsaid key server.
 17. The method of claim 16, wherein: the recipient isone of a plurality of recipients of the message; and said step (b)includes the sender instructing said key server which of said pluralityof recipients said key server is to create said envelopes for, therebyimplementing a policy that at least some of said plurality of recipientsmust go on-line to get said message key while others may read themessage off-line.
 18. The method of claim 16, wherein said step (b)includes said sender providing either said verifier or said secret tosaid key server, thereby permitting said key server to create saidverifier.
 19. The method of claim 18, wherein said step (b) includessaid sender creating and providing said verifier to said key server. 20.The method of claim 16, wherein said step (b) includes said key serverasking an authentication server for either said verifier or said secret,thereby permitting said key server to create said verifier.
 21. Themethod of claim 20, wherein said authentication server employs a memberof the set consisting of already having said verifier, having saidsecret and creating said verifier, having data equivalent to said secretand creating said verifier, and having a hash of said secret andcreating said verifier.
 22. The method of claim 2, wherein said secretis a password.
 23. The method of claim 2, wherein said secret is basedon at least one public or private attribute of the recipient other thana password.
 24. The method of claim 2, wherein the verifier is arecipient verifier and the sender includes a sender verifier with themessage, thereby permitting the recipient to easily reply to the messagein a secure manner.
 25. The method of claim 24, wherein said senderverifier is included in said envelope.
 26. A method for a recipient todecrypt a message secured with a message key, the method comprising thesteps of: (a) receiving an envelope that is based on a secret of therecipient, wherein said secret corresponds with a verifier used tocreate the envelope; (b) opening said envelope to retrieve said messagekey; and (c) decrypting the message based on said message key.
 27. Themethod of claim 26, wherein said envelope is created after the recipienthas received the message.
 28. The method of claim 27, wherein saidsecret is a new said secret, established after the recipient hasreceived the message.
 29. The method of claim 26, wherein said step (a)includes providing said envelope to the recipient with the message. 30.The method of claim 26, wherein said step (a) includes providing saidenvelope to the recipient from a key server.
 31. The method of claim 30,wherein said step (a) includes authenticating the recipient as acondition of said key server providing said envelope.
 32. The method ofclaim 31, wherein: said key server has a recipient list; and said step(a) includes confirming the recipient is in said recipient list as acondition of said key server providing said envelope.
 33. The method ofclaim 31, wherein said authenticating includes providing said key serverwith a credential of the recipient that was issued by an authenticationserver.
 34. The method of claim 33, wherein: said authentication serverstores said verifier, thereby providing a repository for said verifier;and said key server obtains said verifier from said authenticationserver.
 35. The method of claim 33, wherein: said authentication servercreates said verifier; and said key server obtains said verifier fromsaid authentication server.
 36. The method of claim 35, wherein: saidauthentication server creates said verifier based on a transaction withthe recipient other than the request to create an assertion.
 37. Themethod of claim 26, wherein said secret is a password.
 38. The method ofclaim 26, wherein said secret is based on at least one public or privateattribute of the recipient other than a password.
 39. The method ofclaim 26, wherein: said envelope key has been derived based on a keyagreement protocol; and said decrypting uses a symmetric decryptionalgorithm.
 40. The method of claim 39, wherein: said key agreementprotocol is the Diffie-Heilman key agreement; and said decryptionalgorithm is the AES decryption algorithm.
 41. The method of claim 26,wherein said envelope key has been encrypted directly with saidverifier, and said step (b) includes decrypting said envelope directlywith said secret.
 42. The method of claim 41, wherein said step (b)includes decrypting said envelope based on a public key decryptionalgorithm, thereby retrieving said message key.
 43. The method of claim42, wherein said public key decryption algorithm is the El-Gamaldecryption algorithm.
 44. A system for a sender to encrypt a messageintended for a recipient, comprising: a first computerized system ableto create an envelope containing a message key by encrypting saidmessage key based on a verifier that is based on a secret of therecipient; said first computerized system further able to provide atleast said envelope to a second computerized system, wherein secondcomputerized system is employed by the sender; and said secondcomputerized system able to encrypt the message based on said messagekey, thereby permitting the message to be sent securely from the senderto the recipient and the recipient to be provided said envelope so thatsaid secret can be used to open said envelope to retrieve said messagekey and decrypt the message.
 45. The system of claim 44, wherein saidfirst computerized system and said second computerized system are thesame.
 46. The system of claim 44, wherein: said first computerizedsystem is a key server; and said second computerized system receivessaid message key from said key server.
 47. The system of claim 46,wherein said key server has a database in which it stores a copy of saidmessage key.
 48. The system of claim 47, wherein: said secondcomputerized system provides a recipient list to said key server; andsaid key server also stores a copy of said recipient list in saiddatabase.
 49. The system of claim 46, further comprising anauthentication server, and wherein said second computerized systemauthenticates the sender to said key server based on an assertion issuedby said authentication server, as a condition for said key serverproviding said message key to said second computerized system.
 50. Thesystem of claim 46, further comprising an authentication server, andwherein said key server asks said authentication server for either saidverifier or said secret, thereby permitting said key server to createsaid verifier.
 51. A system for a recipient to decrypt a message securedwith a message key, comprising: a computerized system able to receive anenvelope, wherein said envelope is based on a secret of the recipientand said secret corresponds with a verifier used to create the envelope;said computerized system further able to open said envelope to retrievesaid message key; and said computerized system further able to decryptthe message based on said message key.
 52. The system of claim 51,wherein said computerized system receives said envelope from the senderof the message.
 53. The system of claim 51, wherein said computerizedsystem receives said envelope from a key server.
 54. The system of claim53, wherein said computerized system authenticates the recipient as acondition for said key server providing said envelope.
 55. The system ofclaim 54, wherein said computerized system provides said key server withan assertion for the recipient issued by an authentication server. 56.The system of claim 55, wherein: said authentication server creates saidverifier; and said key server obtains said verifier from saidauthentication server.